撰寫 RFC 的時機

RFC 文件的目的是提前溝通跟取得意見回饋。如果變動範圍較小，或是方向已經明確，則不必撰寫 RFC。

常見的 RFC 應用範圍

• 大規模變更

  • 涉及現有技術架構的調整

  • 影響現有系統的外部行為，且該功能已有使用者使用。

• 確定規格

  • API 介面的定義

  • 新功能的範疇與限制

• 有多種實作方法

  • 在眾多解法中，提前確定最佳實作方式。

撰寫 RFC 的好處

1. 理清思緒

撰寫 RFC 能在深入細節前，進行高層次的思考，幫助你探索不同的設計方向，並梳理出明確的想法。

2. 利用團隊智慧，補足資訊落差

透過 RFC 徵求團隊回饋，讓所有人了解正在解決的問題，同時填補知識上的空白。此過程也有助於其他成員在日後接手此程式碼時，能快速上手。

3. 提升代碼審查的順暢度

因為已經經過 RFC 文件討論與建立共識，幫助減少代碼審查階段的爭議，避免後期出現大規模改動。

理論：NABC 模型

為了避免 RFC 充斥過多實作細節，撰寫時可以遵循 NABC 模型強調的四個核心要素：

1. Need：需求確認。在撰寫 RFC 時，首要任務是清楚說明，此提案是為了解決什麼樣的需求？以及確認需求的重要性。

2. Approach：設計解決方案。提出具體的技術解決方案。

3. Benefits：效益評估。討論該解決方案可帶來的預期效益

4. Competition：競爭分析。與其他現有解決方案的比較，探討為何當前提案比其他方案更合適或更具優勢。

實踐指南：RFC 範本格式

Meta / Header

• RFC ID：[編號]

• RFC Name：[RFC 的標題]

• Owner：[提案人的名字]

• Status：[RFC 的目前狀態]

• Start Date：[YYYY-MM-DD]

內文需要包含：

1. 摘要：簡短的描述或要點，快速解釋你想達成的目標。

2. 介紹：提案的背景資訊，提案的動機是什麼？為什麼這個提案很重要？試圖解決的問題。

3. 實施方式：詳細描述技術規範或設計細節，可以考慮包含以下內容：

   • 使用圖表來輔助說明你的想法

   • API 規格描述與範例

4. 安全性考量：分析可能帶來的安全風險，並提出應對措施。

5. 與其他 RFC 的關聯

6. 參考文獻：列出此 RFC 中引用的所有外部參考資料。

總結

透過撰寫 RFC，你能更清晰地表達自己的設計思路，並在開發過程中徵求團隊的回饋。這不僅能幫助你理清問題，也能讓整個團隊共同參與討論，集思廣益，找到最具可行性的解決方案。

透過團隊智慧的協作方式，能避免過度依賴個人觀點，客觀地分析各種方案的優劣，將有助於一次到位，減少反覆修改所浪費掉的時間。

補充常見的 RFC 狀態

• Draft：RFC 的初始狀態。提案者正在撰寫或編輯內容，尚未向更廣泛的受眾徵求意見。

• Review：草案已完成。提案者開始徵求團隊成員或利益相關者的反饋，以便進一步修改或完善文件。

• Accepted：徵求意見回饋的時間已過，提案者已經開始實作。

• Superseded：提案被另一個更新版本或新提案取代

• Withdrawn：提案者主動撤回該提案，因為不再符合需求或其他原因。

延伸閱讀

• 真實範例參考：Couchbase 的 SDK for error handling 提案

• A Structured RFC Process

• RFC: A Structured RFC Process

• Companies Using RFCs or Design Docs and Examples of These